얼마전에 존경하는 김윤수 수석님의 조언에 따라서 락 컨텐션이 심한 멀티쓰레드 잡에 대해 락 파티셔닝 작업을 시행했습니다..
상황 : 직접 구현(..은 아니고 가져온) RB 트리를 여러 쓰레드가 공유함.
락경쟁의 완화 방법..
요약 : 결국 많은 기저 라이브러리들이 해시맵등을 구현할 때 사용한다는 방식을 따르게 됨.
구현 방법 :
트리의 루트를 쪼개서 여러 벌로 나눔.. 트리 루트가 1개일 때의 락 경쟁이 붐빠이로 완화됨. 트리를 쪼개는 방식은 전통적인 접근법임. 즉, 해시값의 나머지 연산.. 해시는 연산비용이 아까워서 사실은 대충 더함... 이 때 문제점은 여러벌의 트리가 공평하게 데이터를 가져갈 확률이 통계적으로 저하되나, 지금 하고 있는 과제에서는 네임 스페이스가 잘 펼쳐져 있어서 별 문제는 없어보임.
이때 부수적으로 장점이 더 발생하는데 트리의 뎁쓰가 줄어들어서 신규 삽입시 부하가 줄어듬.
결과 : 두어배 빨라짐.. 요즘 하는 일이 이십배, 오십배, 천배 빠르게 하기.. 쪽이라서 1분 단축 이런 일에 소홀했는데 결과적으로는 해볼만한 일이었다능.